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Abstract: Sensor-driven services often cause chain reactions, since one service may 
generate an environmental impact that automatically triggers another service. We first 
propose a framework that can formalize and detect such service chains based on ECA 
(event, condition, action) rules. Although the service chain can be a major source of feature 
interactions, not all service chains lead to harmful interactions. Therefore, we then propose 
a method that identifies feature interactions within the service chains. Specifically, we 
characterize the degree of deviation of every service chain by evaluating the gap between 
expected and actual service states. An experimental evaluation demonstrates that the 
proposed method successfully detects 11 service chains and 6 feature interactions within 
7 practical sensor-driven services. 

Keywords: smart home; home network system; sensor-driven service; feature interactions; 
detection; validation 
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1. Introduction 

Research and development of home network systems (HNS) draws great attention as a key technology 
for the smart homes [1,2]. In the HNS, household appliances (e.g., TV, DVD Recorder, air-conditioner, 
lamp, fan) and equipments (e.g., curtain, ventilator, ceiling light) are integrated via a network to achieve 
various value-added services. Moreover, introducing sensors (e.g., temperature, brightness, motion, 
electricity, touch) to the HNS can provide autonomous sensor-driven services. A sensor-driven service 
is triggered automatically, depending on a designated context characterized by sensor values. Examples 
of the sensor-driven services are listed as follows [3]: 

DVD Theater Service (DVD-T): This service allows a user to watch a movie in a theater-like 
atmosphere. When the user touches a touch sensor, a TV is turned on, a light is dimmed, a curtain 
is closed, and a DVD recorder is played. 

Automatic Light Control Service (ALC): This service automatically turns on a light when the room 
becomes dark. When the brightness is lower than 200 lx and the user is in the room, a light is 
automatically turned on. 

Automatic Room Heating Service (ARH): This service automatically heats the room with an 
air-conditioner. When the room temperature is colder than 14 °C, the air-conditioner is turned on with a 
heating mode of 28 °C. 

Energy Saving Air-Conditioning Service (ESAC): This service controls an air-conditioner for energy 
saving. When the total electricity exceeds 1,500 Wm and the air-conditioner is working in a heating 
mode, the temperature of the air-conditioner is adjusted to 25 °C. 

These sensor-driven services work fine when they are used separately. However, when multiple 
services are deployed in the same environment, execution of a service successively triggers another 
service in a certain condition. We define this phenomena as service chain, representing a chain reaction 
of sensor-driven services within the HNS. The service chain often causes undesirable conflicts among 
services, known as the feature interaction problem [3,4]. For the above four services, we can observe the 
following service chains. 

Service Chain CI (DVD-T=^>ALC): When a user runs DVD-T, a light is diminished and the room 
becomes dark. As a result, the condition "brightness is lower than 200 lx" holds. So, ALC is triggered 
and a light is turned on. This ruins the theater-like atmosphere of DVD-T. 

Service Chain C2 (ARH=^ESAC): Suppose that the room temperature drops below 14 °C, and that 
ARH starts the air-conditioner with the temperature setting 28 °C to heat the room. In course of time, the 
electricity consumption rises greater than 1,500 Wm. As a result, ESAC is triggered and the temperature 
setting is adjusted to 25 °C. Thus, the temperature setting of ARH is overwritten by ESAC. 
Service Chain C3 (ALC=^ESAC): Suppose that room brightness drops below 200 lx, and that ALC 
turns on a light. If the total electricity becomes greater than 1,500 Wm at this time, ESAC is 
automatically triggered. 

In the above scenarios, the service chains CI and C2 cause undesirable or unexpected behaviors for 
the users, whereas the service chain C3 causes nothing wrong. Thus, not all service chains are harmful, 
but they are potential factors of feature interactions. So, when deploying many sensor-driven services in 
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the HNS, all service chains should be identified in advance. Furthermore, it is also important to extract 
harmful service chains automatically. 

The goal of this paper is to propose a framework that can characterize and detect all potential service 
chains and feature interactions for given sensor-driven services within the HNS. Specifically, we first 
introduce the ECA (event, condition, action) rules to describe the sensor-driven services. We then 
develop the environment effect model to capture explicitly how each appliance affects the environment. 
Finally, we develop the service chain detection algorithm and feature interaction detection algorithm. 
The service chain detection algorithm can derive concrete conditions describing when the service chain 
occurs. In the feature interaction detection algorithm, we propose a severity evaluation method of each 
service chain by comparison between an expected state by a sensor-driven service and an actual state by 
a service chain including the sensor-driven service. 

We conducted a case study with 7 practical services operated in our HNS. As a result, we could detect 
1 1 service chains, in which 6 harmful feature interactions are identified. 

2. Preliminaries 

2. 1. Home Network System 

A home network system (HNS) consists of multiple networked appliances connected to the local area 
network at home. Each networked appliance has control APIs, with which users or software agents can 
control the appliance via the network. Each appliance is generally equipped with a network adapter, a 
processor and a storage. 

A HNS typically involves a home server, which manages all the appliances deployed. It also plays a 
role of gateway to the external network. More importantly, various value-added services are installed in 
the home server. When a service is requested, the home server executes APIs of the appliances according 
to the logic specified in the service. As seen in Section 1, a service can orchestrate different appliances 
at the same time. In our research group, we are building an actual HNS (CS27-HNS) using legacy home 
appliances [5]. 

2.2. Sensor-Driven Service in HNS 

Introducing sensors to the HNS can make the services autonomous and context-aware. Since the 
sensors can capture events and contexts, we use them as triggers of the service. In this paper, we write 
sensor-driven service to represent any HNS service triggered by a sensor. For example, let us take 
Automatic Light Control Service (ALC) in Section 1 . The condition "the brightness is lower than 200 lx" 
can be evaluated by a light sensor. Thus, ALC can be implemented as a program which invokes API 
Light . on ( ) when the reading of the light sensor becomes less than 200. 

The sensor-driven services are smart and convenient in the sense that they do not require human 
operations. However, if many services are deployed in the same environment, they often cause 
unexpected service chains, as seen in Section 1. Since the number of potential service chains grows 
combinatorially in the number of services, we need a systematic method to detect and resolve the 
service chains. 
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2.3. Previous Work: Feature Interactions in HNS 

In our previous work [3,4], we proposed an object-oriented modeling method to formalize and detect 
feature interactions in the HNS. In this method, we modeled every appliance (or an environment) as an 
object with properties and methods. The properties characterize the internal state of the appliance (or the 
environment), while the methods correspond to the API. Also, we defined every service as a sequence 
mi(); m 2 (); ■■■', m n0 of the appliance methods. Then, we defined that a feature interaction between 
services si and s 2 occurs if a method m() of s\ and another method m'Q of s 2 conflict, either locally 
on an appliance object (called, appliance interaction) or indirectly via an environment object (called, 
environment interaction). However, this method assumed that every service is triggered manually by the 
user. Thus, the sensor-driven services and the incidental service chains were beyond the scope. 

3. Modeling Sensor-Driven Services and Service Chains 

3.1. Describing Sensor-Driven Services with ECA Rules 

In order to capture the nature of the sensor-driven services, we here introduce the ECA (event, 
condition, action) rules [6] for the service description. A sensor-driven service S is defined by 

S = {E s , C s , A s ) where 

• Es is an event that triggers S, which is defined by a condition over a single environment property. 

• Cs is an enabling condition to determine the execution of S. On detecting Es, S is actually 
executed only when Cs is satisfied. Cs is defined by a condition over appliance properties and 
environment properties. 

• As is an action to be executed, which is defined by a sequence mi(); m 2 ();...; m n Q of 
appliance methods. 

This model newly involves the event and condition, compared to the one in the previous work. 



Figure 1. Service description of sensor-driven services with ECA rules. 
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Figure 1 shows service descriptions of seven sensor-driven services, including the 4 services seen in 
Section 1 and 3 more described below. 

Automatic Room Cooling (ARC): This service automatically cools down the room, using an 
air-conditioner. When the room temperature is warmer than 25 °C, the air-conditioner is turned on 
with a cooling mode of 23 °C. 

Leaving Home (LH): This service shuts down all appliances when a user leaves home. When the user 
touches a button in the entrance, a TV, a DVD player, an air-conditioner and a light are turned off, and a 
curtain is closed. 

Energy Saving in Absence (ESIA): This service automatically turns off appliances for energy saving 
in user's absence. When a sensor detects that nobody is in the room, the service turns off a TV, a DVD 
player, an air-conditioner and a light. 

In Figure 1, env denotes a prefix of an environment property. Each event (or condition) is supposed 
to be detected (or evaluated, respectively) by appropriate sensors in the HNS. In each action, A.m() 
denotes a method m ( ) of an appliance A. Let us take the description of ALC. The event of ALC 
is env. brightness < 200, specifying that the service is triggered when the brightness is less that 
200 lx. The condition env . absence == false means that the service should be enabled only when 
somebody is in the room. If ALC is executed, the light is turned on with brightness level 10 as specified 
in the action Light . setBrightness ( 10 ) . 

3.2. Modeling Environmental Effects of Appliances 

To detect the service chains, we have to know how much effect is given to the environment as a result 
of a service. Such effect is produced by appliance methods executed as an action of the service. For 
example, Light, on () increases env. brightness, and Air-Conditioner . cooling ( ) decreases 
env . temperature. Therefore, we propose an environment effect model for each appliance, to define 
explicitly how the appliance gives the environmental effects. 

As shown in Section 2.3, every appliance can be regarded as an object with internal states. Therefore, 
we model every appliance as an FSM (finite state machine) specifying the effects within transitions. Let 
d be an appliance. The environment effect model of d is defined by an FSM EMd = (Sd, Md, Td, sq, e<f), 
where 

• Sd is a set of states of d. 

• M d is a set of appliance methods of d. 

• Td : Sd x Md — > Sd is a state transition function. 

• so £ Sd is the initial state. 

• ed is an environment effect function, associating each transition t E T d with a set of expressions 
over environment properties. 

Tables 1 shows the environment effect models of an air-conditioner, a TV and a light, respectively. 
Each table describes an FSM in a table form, where a row represent a state, a column represents a 
method. Each entry represents a state transition, containing the effects to the environment and the next 
state (labeled by next). In the effects, =, += and -= respectively represent substitution, addition and 
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subtraction operators. For example, Table 1(b) represents that the TV has two states OFF and ON. If 
method on() is executed within OFF, the state moves to ON. At this time, as the environment effects, the 
electricity is increased by 500 Wm, and the brightness is increased by 200 lx. 

Table 1. Environment Effect Model, (a) Air-Conditioner; (b) TV; (c) Light. 

Method 



offO 



heating(setTemp) 



cooling(setTemp) 



next : OFF 



OFF 



env.electricity += 1500 env.electricity += 1500 
env.temperature = setTemp env.temperature = setTemp 
next : HEATING next : COOLING 



State HEATING 
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env.temperature = setTemp env.temperature = setTemp 
next : HEATING next : COOLING 
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COOLING env.temperature = 10 next : HEATING next : COOLING 

next : OFF 



(a) 
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Assumption 1: Effects of every appliance to environmental values by each appliance are 
reflected instantly. 

For some environment properties, the effect may be given gradually. For example, it takes time for 
an air-conditioner to change the room temperature in the designated value. However, in this paper we 
define the environment effect by an expected value converged after sufficient time. 

We assume that every appliance d in the HNS is first in the initial state of EM d . When a service 
S = (Es, Cs, As) is executed, each method d.mQ in As is executed one by one. Then, a corresponding 
transition t in EM d occurs and environment effects e(t) are accumulated to the environment. 

3.3. Service Chain 

A service chain occurs when the result of one service triggers another service, successively. We try 
to formalize this mechanism using the proposed service description and the environment effect model. 
Let Sa = (E Sa ,Cs a , A Sa ) and Sb = (E Sb ,Cs b , A Sb ) be two services. A service chain from Sa to 
Sb, denoted by Sa =>• Sb, occurs when the environment effects produced in A Sa create an environment 
(state) where Es B is satisfied. A chain Sa => Sb may cause another chain Sb => Sc, creating Sa => 
Sb => Sc- Also, if Sb triggers Sa again, then a loop Sa =>• Sb =>• Sa =>• Sb =>• ••• may be produced. 

Note that the occurrence of Sa Sb is conditional. That is, it depends on the current states of the 
appliances and the environment. For example, for ALC=^ESAC in Section 1, if no other appliance is 
working before the execution of ALC, ESAC may not start. Therefore, it is important to identify the 
pre-condition of the service chain, explaining when the chain occurs. We denote [cond]SA => Sb to 
represent that a chain Sa =>• Sb occurs when a pre-condition cond holds. 

3.4. Feature Interactions in Service Chain 

Service Chain may cause feature interactions. However, all service chains do not lead to harmful 
feature interactions. In the chain scenarios described in section D, scenario CI is considered as harmful 
one. In the scenario CI, service chain DVD-T-ALC prevents a user from watching a movie in a 
theater-like atmosphere contained in the requirement of DVD-T. On the other hand, in the chain scenario 
C2, ESAC makes preset temperature of the air-conditioner lower than a user's requirement in ARH. 
Although this scenario is also considered as a feature interaction, a user may accept the change of room 
temperature for 1 degree. Moreover, energy saving, which is one of the requirements in ESAC, is satisfied 
in the scenario. 

The service chain causes various feature interactions which can be serious or acceptable. Then, we 
propose a method to evaluate the severity of feature interactions. 

4. Detecting Service Chains among Sensor-Driven Services 

4. 1. Service Chains Detection Algorithm 

Now we present an algorithm that can automatically detect the service chains among sensor driven 
services, using the proposed service description and the environment effect model. Specifically, for 
a given pair of services Sa = (E Sa ,Cs a , A Sa ) and Sb = (E Sb ,Cs b , A Sb ), the algorithm checks if 
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Sa Sb occurs. Moreover, if the chain occurs, the algorithm derives a concrete pre-condition cond 
such that [cond]SA =>■ Sb holds. Intuitively, the algorithm checks if the environment effects produced 
by A Sa may create a situation where E Sb is satisfied, as discussed in Section 3.3. It consists of the 
following nine steps. 

Step 1: Pick out an environment property p in E Sb . 

Step 2: By analyzing A Sa , obtain a set M p = {mi(),m 2 (), ...,m n Q} C A Sa of appliance methods 
where every rriiQ has an environment effect on p. 

Step 3: For every rriiQ G M p , analyze the environment effect models and obtain a set T m . of any state 
transitions on which rriiQ appears. 

Step 4: Construct a Cartesian product T p = T mi xT m2 x...xT m „. Each elements = (ti, t 2 , t n ) G T p 
represents a sequence of transitions each of which has an environment effect on p. 
Step 5: For each tt = (t%, t 2 , t n ) G T p , calculate the total environment effect TE{tt) = 
E [e p (ii), e p (t 2 ), ...,e p (t n )}, where e p (ti) is an environment effect added to the environment property 
p by the transition The semantics of E will be defined later. 

Step 6: Let s e be any environment state where Sb is enabled (i.e., E Sg holds), and let Sd be any state 
where Sb is disabled (i.e., ~^E Sb holds). For each tt G T p , if there exists such a pair (s d , s e ) that TE{tt) 
changes the state s d into s e , then detect a service chain S^ =>- 5b- For this, we call tt potential transition 
sequence of the service chain. 

Step 7: If tt = (ti, i 2 , tn) G T p is a potential transition sequence of the service chain, for each ti 
(1 < i < n), derive a condition dcondi of an appliance where ti is executed. Then, make a conjunction 
dcond p = dcondi A dcondi A ... A dcond n , which is a pre-condition of the service chain w.r.t. the 
appliances. In addition, obtain a condition econd p on the environment where of Step 6 is satisfied, 
which is a pre-condition of the service chain w.r.t. the environment. 

Step 8: Validate that cond p = dcond p A econd p does not contradict to Es A A Cs A - If there is no 
contradiction, derive cond p as the pre-condition of Sa => Sb- If there is a contradiction, Sa is disabled. 

50 conclude that Sa => Sb does not occur. (End) 

Let Vi be the value of the environment effect e p (tj). The semantics of E in Step 5 is defined by one of 
the following SI, S2 or S3, depending on the environment property p interested. 

51 (Arithmetic Sum): E [e p (ti), e p (t 2 ), e p (t n )] = v\ + v 2 + ... + v n . This semantics is taken when p 
is a cumulative property, including brightness, sound volume, etc. 

S2(Maximum Value): E [e p (ti),e p (t 2 ), e p (t n )} = max(vi, v 2 , ...,v n ). This semantics is taken when 
the value of p is overwritten by the maximum one, including the temperature of heater, wind level, etc. 
S3(Minimum Value): E [e p (tx), e p {t 2 ), ...,e p {t n )\ = min{vx,v 2 , ...,v n ). This semantics is taken when 
the value of p is converged to the minimum one, including the temperature of air-conditioner. 

We briefly summarize the purpose of each step of the algorithm. Step 1 finds the key property p by 
which the service chain Sa =>■ Sb may occur. Step 2 extracts appliance methods that potentially give 
an effect to p. Step 3 identifies all state transitions related to the methods within the environment effect 
models. Step 4 derives all possible combinations of the transitions affecting p. Step 5 calculates the total 
impact to p produced by each of the combinations. Step 6 examines if the total impact can trigger Es B 
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or not. Step 7 derives the pre-condition of the service chain. Finally, Step 8 validates if the pre-condition 
does not contradicts to the enabling condition of Sa ■ 

In our service chain detection method, the conditions under which the potential conflicts may arise 
are derived from static structures of service models. Since our method does not need to utilize an 
exhaustive search such as model checking, the state explosion problem does not occur if service 
complexity increases. 

4.2. Running Example 

Using the proposed algorithm, we demonstrate to detect the service chain CI (DVD-T=^ALC) in 
Section 1. In this example, we use the service description in Figure 1, and the environment effect model 
of the appliances in Table 1. 

4.2.1. Detection of Service Chain (DVD-T ALC) 

In Step 1, we pick up env. brightness from Ealc an d know that the brightness is the key 
property of the service chain. In Step 2, we obtain methods TV. on () , Light . setbrightness (1) 
from Advd-t, since they have effects on env . brightness. In Step 3, we identify the 
corresponding transitions in the environment effect models. In Table 1(b), we find T TV . 0 n{) = 
{(OFF, on () ,ON) , (ON,on() ,ON)}. In Table 1(c), we find T LighLsetbrightness{1) = {(OFF, 
setBrightness ( 1 ) , ON), (ON, setBrightness ( 1 ) , ON)}. Step 4 constructs a product 
Trv.onO x T Lightsetbrightness{1) to derive the following four transition sequences. 

• tti = ( (OFF, on () , ON) , (OFF, setBrightness (1) , ON) ) 

• tt 2 = ( (OFF, on () , ON) , (ON, setBrightness (1) , ON) ) 

• tt 3 — ( (ON, on ( ) , ON) , (OFF, setBrightness (1) , ON) ) 

• tti — ( (ON, on ( ) , ON) , (ON, setBrightness (1) , ON) ) 

Step 5 calculates the total the environment effect to env. brightness. Since the brightness is 
cumulative, we follow the Semantics SI. 

• TE{ttx) = + 200 + 100 = +300 

• TE(tt 2 ) = + 200 +100 (1-bLevel) =300 - 100 * bLevel 

• TE(tt 3 ) =+ 0 + 100 = +100 

• TE(tti) =+ 0 + 100(1 - bLevel) =100 - 100 * bLevel 

In Step 6, let Sd be any state where ALC is not triggered, i.e., -*Ealc = env. brightness > 200 
holds. Also, let s e be any state where ALC is triggered, i.e., Ealc = env. brightness < 200 holds. 
Among tti to tt 4 , we want to find any transition sequences that can change s d to s e . Since both tt\ and 
tt 3 give positive impact to the brightness, they cannot move s d to s e . So, tt 2 and tt 4 are chosen as the 
potential transition sequences of the service chain. 

In Step 7, we first derive the pre-condition of the service chain from tt 2 . In order for the sequence tt 2 to 
be executed, the TV must be OFF and the light is ON beforehand. So, dcondbright = [TV is OFF A Light 
is ON]. From ->Ealc> we obtain a condition env. brightness > 200 to be satisfied before DVD-T. 
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Also, as for the condition after DVD-T, we have env. brightness +TE(tt 2 ) < 200 so that ALC is 
triggered. Therefore, econd bright = [ 200 < env . brightness < 100 * bLevel — 100]. Similarly, we 
derive the pre-condition from tt 4 . As a result, we can see that the service chain DVD-T=^ALC occurs 
when DVD-T is executed under the one of the following pre-conditions. 

• condl: TV is OFF, Light is ON and a condition [ 200 < env . brightness < 100 * 
bLevel — 100] holds, or 

• cond2: TV is ON, Light is ON and a condition [ 200 < env. brightness < 100 * bLevel+100] 
holds. 

These pre-conditions are validated in Step 8 that they do not disable DVD-T. So, we finally detect 
[condl] DVD-T ALC and [cond2] DVD-T => ALC. 

5. Estimation of the Severity of a Service Chain Using Prior Expectation of Sensor-Driven Service 

5.1. Severity of a Service Chain 

As described in Section 3.4, every service chain does not lead to harmful feature interactions. Then, 
we define the degree of severity of a service chain, in order to evaluate whether the service chain is 
harmful. Intuitively, we consider that the service chain is serious, when the state after a service execution 
differs from the state after a service chain significantly. We define a set es = (v i, v 2 , v n ) of arbitrary 
value of environment properties pi,p 2 , ...,p n as an environmental state. When an environmental state 
esfSU] at the time of Sa being executed independently and other environmental state of esfSU =>• Sb] at 
the time of a service chain cs[Sa Sb] being executed are compared, we estimate that the gap between 
both environmental states is large. 

5.2. Prior Expectation in a Sensor-Driven Service 

It is also dependent on the requirement(pn'or expectation) which a user expects to be satisfied by 
a service whether the service chain is serious or not. The prior expectation is expressed as a state 
of appliances and environment properties contained in the main purpose of a service. Table 2 shows 
examples of prior expectation in each service. In the table, the prior expectation in ARH is related to 
"indoor temperature". Similarly, the prior expectation in ESAC is related to "electricity". Therefore, 
when evaluating the degree of severity of a service chain, it is necessary to narrow down a state es in the 
view point of the prior expectation. 



Table 2. Service prior expectations. 
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We define a projection es = (v 1 ,v 2 , v n ) to I = {pa, ...,p ik }(a set of environmental properties) as 
proji(es) = (vn, ...,Vik). Let I a be a set of environment properties related to the prior expectation in 
Sa- Moreover, let esfS^] be a state at the time of Sa being executed independently, and ss[Sa =>- S B ] 
be a state at the time of Sa =>• -Sb being executed. Here, projj A (es[SA]) can be considered as a prior 
expectation expected by a user to S^. Similarly, proji A (es[SA => Sb]) is regarded as an actual state at 
the time of Sa => S B being executed. 

5.3. Estimation of Service Chain Severity 

We estimate whether a service chain causes serious feature interaction or not, depending on whether 
the difference between proji A (es [Sa] ) which is expected by a user to Sa and proji A (es [Sa] ) is below a 
threshold value r. Here, r is a given value experientially by a user or the service creator. 

Assumption 2: A sensor-driven service Sa = (E Sa ,Cs a , A Sa ) and Sb = (E Sb ,Cs b , A Sb ) cause a 
service chain [cond]SA =>• Sb- A set of properties which a user expects to the Sa is I a = {pn, ■■■,Pik}- 
Each pij is given a threshold value r(p^). 

Step 1: Create a set of state es = (t>i, v 2 , u n ) which is formed by the cond. 

Step 2: In the es, the method of A Sa is virtually invoked according to each appliance model. Let 
Ua = (ti,t 2 , ■■■,t s ) be a set of transition sequence of the appliance model performed. We calculate 
esfSU] = (v[, v' 2 , ■••,v' n ) by compounding the total environment effect TE(Ua) (described in Section 4.1) 
to es. 

Step 3: In the es, A Sa and A Sb are invoked in order. Let Ua,b = (h,h, • ••,*«) be a set of transition 
sequence performed in the service chain. We calculate es[SU =>- Sb] = (v*, v 2 , v*) by compounding 
the total environment effect TE(Ua,b) to each element in es. 

Step 4: Calculate the gap between a state caused by prior expectation and an actual state by the service 
chain as follows. proj lA (es[S A ]) - proj lA (es[S A S B ]) = Ki, v' i2 , v' ik ) - (v^, v* 2 , v* ik ) = 
Ki - Va,v' i2 - v* 2 , ...,v ik - v* k ) 

Step 5: Determine Sa S B as a serious service chain if \v'^ — > r(p»j) (1 < j < k) is true. 

Here, if a service has multiple environment properties as the target of prior expectation, our algorithm 
calculates each severity separately. For instance, if a service has brightness property and temperature 
property as the target of prior expectation, severities of the service in the view point of brightness and 
temperature are calculated respectively, and the service is judged whether the service chain is a feature 
interaction or not. 

Second, if a service does not include any prior expectation, it is difficult to capture the user's desire 
about the service. We assume the prior expectation depends on user's requirement or desire. Therefore, 
in our future approach, though the service chain is detected, the severity of the service is not calculated. 

Our method to estimate the severity of service chains generates a set of state which satisfies the 
conditions. Though the set of state which satisfies the conditions may exist infinitely, environment 
properties not included in prior expectations are treated symbolically in our method. For example, 
a state about a service which includes brightness property as the prior expectation is expressed like 
(Temperature, Brightness, Electricity) = (x, 800, y) in internal implementation. An environment property 
included in a prior expectation may take various values. Two or more typical values should be checked 
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for estimating severity. The typical values should reflect user's desire or some kinds of situation in which 
the service is invoked. Concrete methods to configure the property values for severity estimation are left 
for our future research. 

5.4. Running Example 

We evaluated the degree of severity about the service chain in Section 1 . Here, we focused on three 
properties, such as temperature, brightness and electricity in HNS. Moreover, the threshold of deviation 
tau is 2 (°C), 500 (lx), and 500 (W), respectively. 



5.4. 1 . Severity Evaluation of DVD-T ALC 

In Step 1, we create an environmental state es = (temperature, brightness, electricity)= (24, 800, 50) 
which may trigger the service chain. Here, current brightness setting of the light in the services is 
level 8. In Step 2, when only DVD-T is invoked, es[DVD - T] changes to (24, 100, 850). In Step 3, 
when DVD-T and ALC are invoked in order, es[DVD - T ALC] changes to (24, 1000, 850). In 
Step 4, if I DV d-t is {brightness}, the gap is calculated as follows. proji DVD _ T (es[DVD — T]) — 
proj lDVD _ T {es[DVD - T] ALC) = (100) - (1000)= (-900) That is, user's prior expectation of 
brightness in DVD-T has significant deviation: —900 from the actual environment state by the service 
chain. In Step 5, | — 900 1 > r (brightness) = 500. As a result, this service chain can be considered serious. 

Figure 2. Service chain/FI detection system Architecture. 
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6. Implementation of Service Chain/feature Interaction Detection System 

6.1. Architecture 



Figure 2 shows the architecture of our service chain/feature interaction detection system. Our system 
consists of a state transition machine service, a service chain detection service, a severity evaluation 
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service and an offline service chain/feature interaction detection controller. The chain detection 
controller detects service chains and feature interactions by invoking the service chain detection service 
and the severity evaluation service. Henceforth, the details of each component are explained. 

6.1.1. State Transition Machine Service 

The state transition machine service calculates the environment effect e(t) for each appliance based 
on the appliance model. 

This service exhibits the following methods. 

imulate(String[] methods) :SimulationResult[] This method receives an array of appliance method 
(String type) as an argument, and returns an array of the SimulationResult class. This method returns 
SimulationResult class which contains combination of the environment effect and the appliance state 
transition based on the given appliance method sequence. The SimulationResult has the following 
attributes. 
SimulationResult 

-effects(Effect[]) : An array of the environment effect for each environment property 
-transitions(Transition[]) : An array of appliance transition sequence caused by appliance method 
execution 
Effect 

-propertyName(String) : A name of an environment property 
-value(double) : Degree of environment effect 
-operator(String) : Operator is any one of " = " " += " ". = " 
Transition 

-deviceName(String) : Device name 
-preState(String) : A state before transition 
-postState(String) : A state after transition 

This method controls Steps 2-5 in Section 4.1 and Steps 2 and 3 in Section 5.3. 

6.1.2. Service Chain Detection Service 

The service chain detection service stores the service models and detects a service chain between 
given sensor-driven services. This service exhibits the following method. 

detectChain(String servicel, String service2): boolean This method receives names of two sensor- 
driven services (a source service and a destination service), which may cause a chain reaction, as 
arguments, and returns a boolean value which indicates whether there exists a service chain. This method 
controls our service chain detection algorithm in 4.1. First, this method gets an action of the source 
service and an event of the destination service from the service models. Next, this method calculates 
a total environment effect of the source service with using the simulate() method in the state transition 
machine service. 
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6.1.3. Severity Evaluation Service 

The severity evaluation service stores service models, and evaluates degree of a severity of a given 
service chain. This service exhibits the following method. 

detectFI(String servicel, String service2): boolean This method receives names of two sensor-driven 
services (a source service and a destination service), which may cause a chain reaction, as arguments, 
and returns a boolean value which indicates whether there exists a feature interaction. This method 
controls our severity evaluation algorithm in Section 5.3. First, this method gets method information 
in the service model. Next, this method calculates an environment state after execution of the source 
service, and another environment state after the occurrence of the service chain, respectively. Then, this 
method calculates the degree of deviation of the environment state for every property which is related to 
the prior expectation in the source service which may cause the chain reaction. 

6.2. Implementation and Evaluation 

The total lines of code of our program are about 4,300, and the programming language used 
for development is Java. We use the actual HNS(CS27-HNS) developed by our research group for 
sensor-driven services. All the services included in the service chain/feature interaction detection system 
were deployed under the following environments. 

• Server Specification: 950 MB RAM 2.00 GHz WinXP Pro 

• Tomcat 5.5 

• Apache Axis 2.2 

• JavaJDK5 

We performed the service chain/feature interaction detection for the 7 services in Figure 1 . Our system 
required about 16 seconds for detecting the service chains and the feature interactions. 

7. Case Study 

To evaluate the proposed method, we have conducted a case study to detect all service chains and 
feature interactions among the seven sensor-driven services shown in Figure 1 . 

Table 3 shows the result. In the table, a row represents a service triggered first (called first service, say 
Sa), and a column represents one triggered second (called second service, say Sb)- Each entry shows 
whether a service chain Sa => Sb occurs or not. Out of all 42 (= 7 x 6) possible combinations, 1 1 service 
chains and 6 feature interactions were automatically detected by our system (marked as Chain and FI 
in Table 3). Scenarios of DVD-T^ALC and ARH^ESAC are the same as CI and C2 in Section 1, 
respectively. Scenarios of other FIs are explained below. 
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Table 3. Service chain/Feature Interaction detection result. 
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7.1. Service Chain Scenario (ESIA^ARH) 

In a day of winter, as nobody remains the room, ESIA turns off all the appliances. This situation 
makes the temperature decrease, and ARH is triggered in due course. The service chain violates the goal 
of energy-saving of ESIA. 

7.2. Service Chain Scenario (LH^ARH) 

This service chain is similar to ESIA=^ARH. As a user presses the button of LH, all the appliances are 
shut down. This makes the temperature decrease and has ARH triggered. This service chain is against 
the user's requirement that all the appliances should be off while leaving home. 

7.3. Service Chain Scenario (ARH^ARC) 

As the temperature decreases, ARH is triggered to heat the room using the air-conditioner. This makes 
room warm enough to trigger ARC to cool the room, which violates the goal of ARH. The algorithm 
derives a pre-condition that the air-conditioner is OFF or working with the temperature setting 25 °C 
or less. 

7.4. Service Chain Scenario (LH^ALC) 

If a user presses the button of LH in the night, all the appliances are shut down, and the room becomes 
dark. Then, ALC is triggered and the light is turned on again. The chain violates the user's requirement 
that all the appliances should be off while leaving home. The algorithm derives a pre-condition that 
[200 < env. brightness < 200 + 100* Light . bLevel, the light is ON, and TV is OFF]. 
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8. Discussion 

8. 1. Advantage and Limitations 

For given sensor-driven services, the proposed method can detect all potential service chains and 
feature interactions automatically. It also derives concrete pre-conditions for every service chain 
detected. Therefore, the proposed method can make service developers aware of unexpected service 
chains in advance. Furthermore, we could calculate the degree of severity of each service chain and 
judge the undesirable feature interactions resulting from the service chain. 

In this sense, the proposed method is useful especially for the offline validation at the design stage of 
the services. 

On the other hand, the detected harmful service chain needs to be resolved. However, this paper does 
not show the concrete resolution method for such service chains. It is necessary to define the suitable 
resolution method according to the degree of severity of the service chain. A service developer and a user 
are to determine the magnitude of the deviation experientially. More systematic determination method 
for the deviation is our future subject. 

It is significant problem to determine adequate value of the r. The value of r is a criterion which 
indicates the degree of the severity of detected feature interactions. Accordingly, wrong value of r does 
not capture the user's desire. On the other hand, since the value of r depends on user's requirement, 
desire, or environment where sensor-driven services are deployed, it is significantly difficult to decide 
the value statically in advance. Currently, a method to configure the value of r and resolve feature 
interactions are both left for our future research. In our next research, we consider about a method to 
use the value small enough as an initial value of r. In the approach, feature interactions are detected 
based on the initial value of r, and a user decides and conveys whether each feature interaction is 
acceptable or not. The recursive feedback process between the user and our system make the value 
of r configured gradually. 

8.2. Related Work 

Kolberg et al. [7] presented a classification of feature interactions in smart home, where our service 
chains can be categorized as the sequential action interaction (SAI). However, the concrete detection 
method of the service chains was not described. Wilson et al. [8] took the environment effects of 
the appliances for detecting feature interactions. However, since the amount of the effects was not 
explicitly considered, it would be difficult to derive detailed pre-conditions of the service chains. The 
ECA rules have been often used for detecting policy conflicts [6,9,10]. These methods basically focused 
on action conflicts only, and the service chains were not explicitly considered. In [11], we proposed a 
service-oriented framework that facilitates development of individual sensor-driven services. However, 
this method did not cover interactions among multiple services. 

In distributed system, many techniques for detecting policy conflict based on policies such as 
Authorization Policy and Obligation policy have been proposed. Lupu et al. [12] have classified 
policy conflicts occurring in distributed systems and proposed conflict resolution method according to 
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the classification. Dunlop et al. [13] have proposed dynamic and scalable policy conflict detection 
method. In the method, conflict DB stores the combination of the policies which may cause conflicts. 

In the viewpoint of conflict detection, these researches differ from our proposed method detecting 
conflicts based on the service chain using the HNS component model. On the other hand, it is significant 
to apply the dynamic and scalable conflict detection method to our detection technique. 

Charalambides et al. [14] have proposed conflict analysis using Event Calculus in the domain of QoS 
management. In the analysis method, they used abductive reasoning to detect the potential conflicts. 
Furthermore, they have identified a number of potential conflicts, and have classified them. In the 
classification, the redundancy conflict and the mutual exclusion conflict can be considered as some kinds 
of feature interactions in HNS [4] However, in this paper, we proposed FI detection method based on the 
service chain which differs from conventional FIs such as redundancy and mutual exclusion. 

Shankar et al. [15] have proposed a method to detect conflicts and cycles in policies based on their rule 
framework "Event-Condition-Precondition-Action-Postcondition" in pervasive systems. Their conflict 
detection method using the rule framework ECPAP resembles our proposed method. However, since 
they assume that the framework is used in general-purpose pervasive systems, the subjects peculiar to the 
sensor-driven services in HNS have not necessarily been solved. We have proposed our framework which 
takes multiple different kinds of environment properties into account. Furthermore, our framework 
provides the concrete conditions under which each potential conflict may arise and estimation of severity 
of the conflicts quantitatively. 

9. Conclusions 

In this paper, we have proposed a method that detects service chains among sensor-driven services 
in the home network system (HNS), and evaluates the severity of the detected service chains. The 
proposed method adopts the ECA rules for the service description, and introduces the environment effect 
model to define the effect of the appliances to the environment, explicitly. We also implemented the 
proposed method as a tool and detected 1 1 service chains and 6 feature interactions among 7 practical 
services. Based on our method, we proposed systematic resolution schemes of undesirable service 
chains. Extending the method for general sensor services outside the HNS is also a challenging issue. 
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